Modern microprocessors are extremely complex, and the task of debugging them is a difficult one. Microprocessor designers commonly use a software functional model that simulates the architectural behavior of the microprocessor as a debugging tool. A software functional model can be very useful because it can simulate the execution of a large number of instructions quickly relative to other software models, such as a Verilog simulator. A software functional model executes a single instruction at a time according to the architectural definition. A software functional model is very useful for debugging a single core processor.
The software functional model may also be used to debug a multi-core processor. A different respective instance of the software functional model may be used to simulate the execution of instructions on each of the cores. This works well as long as the cores are not interacting with one another. However, there are some multi-core processor bugs that only manifest in the context of memory access interactions between the multiple cores, particularly when the cores are sharing a memory location, such as a software semaphore. The memory accesses to a shared memory location are essentially asynchronous to each other. For example, consider the case in which a first core is looping reading a semaphore waiting for a second core to write the semaphore. Unless the two instances of the software functional model execute their instructions in a manner that sufficiently approximates the order in which the actual processor executes instructions when the bug manifests, the software functional model tool may not be very useful in debugging the dual-core processor. Therefore, what is needed is a way to control the order in which the simulated cores execute instructions relative to one another that approximates the order of the post-silicon multi-core processor.